I feel this belongs to theResult returned from the transition tool after executing the state transition.

Environment is more for things that affect the EVM execution and/or are observable in the EVM context.

If we put it in Result, we can catch it in here:

Hi @marioevz I see this differently. The test supplies the following to the client as part of a block:

1. A list of transactions
2. SSZ encoded block access list (BAL)
3. BAL hash

In the PR (1) and (2) is part of a test. (3) is computed by the framework from (2).

State transition

The client's state transition function takes all three to produce a block. In addition to executing the transactions, the client:

1. Computes its own copy BAL and then
2. Computes BAL hash

The Client and NOT test verifies hash

The client MUST reject the block if computed hash does not match the provided one. ref: spec

If hash is not supplied as an input to the client it will not be able to perform this check. Hence its inclusion in ENV.

Let me know if I misunderstood anything in this flow.

We are trying to fill tests here to generate a test fixture with a built block to then test against clients. So we are essentially testing the EL's ability to locally build a valid block when we're filling tests. This block is then sent as a payload to a client via the test fixture. So I feel like we could actually perform the check at the Result level here. If we build our BALs and compute our own hash to check against, what we need from the filler (let's say this is EELS) is that they compute their own BALs internally, generate the hash, and we validate that this hash is the expected hash in the result with header_verify=Header(bal_hash=correct_bal_hash). And we can test any invalid cases with rlp_modifier=Header(bal_hash=invalid_bal_hash) and exception=BlockException.INVALID_BLOCK_HASH (or a more appropriate bal hash exception).

The client MUST reject the block if computed hash does not match the provided one. ref: spec

I think this comes into play when we're executing the test payload against a client. They will now have a filled block in the test fixture, with the hash that we validated is correct, and they should indeed correctly raise on an invalid hash according to the spec.

Am I missing anything @raxhvl? Does this go along with what you were thinking @marioevz?

I think this should be more of a verification that the BAL-specific tests do, rather than something you have to pass on every test.

There's two ways of handling BALs in tests IMO:

1. The test is unconcerned with BALs, so we take the value that was returned from the transition tool for granted and just put it in the result.
2. The test is meant to verify BALs, so we add the header_verify field when constructing the block for the result from the transition tool to be cross-checked with the one that the test expects.

The BAL will be either way be verified at client level when the test is being executed either in hive or by the client consumer, and the test should fail if the BAL hash does not match what the filled test says.

Taking into account, I think this specific example should be rewritten as something like:

Assuming bal.serialize().hash() returns the hash that should be placed in the header.

Continuing the discussion, client simply rejects a block with invalid hash. For the test, client behaves like a black box which takes all three inputs to either accept or reject the block.

Just getting to this comment now but this agrees with the way I'm thinking about it as well as I described above.

The client will build its own BAL and compute its own hash. We do so internally in the test and will need validate that it's correct after filling.

So what we need is a built BAL that can be hashed in the appropriate way (this can be bal.hash, bal.serialize().hash(), or however we want to wire it) and we need to check here that the hash is as expected. When the client runs this filled test against it, the payload from the fixture is built correctly (or if invalid will have an expect_exception) and this will test that the client independently builds its own BAL and hashes appropriately.

Let me know if I misunderstood anything in this flow.

We are trying to fill tests here to generate a test fixture with a built block to then test against clients. So we are essentially testing the EL's ability to locally build a valid block when we're filling tests. This block is then sent as a payload to a client via the test fixture. So I feel like we could actually perform the check at the Result level here. If we build our BALs and compute our own hash to check against, what we need from the filler (let's say this is EELS) is that they compute their own BALs internally, generate the hash, and we validate that this hash is the expected hash in the result with header_verify=Header(bal_hash=correct_bal_hash). And we can test any invalid cases with rlp_modifier=Header(bal_hash=invalid_bal_hash) and exception=BlockException.INVALID_BLOCK_HASH (or a more appropriate bal hash exception).

The client MUST reject the block if computed hash does not match the provided one. ref: spec

I think this comes into play when we're executing the test payload against a client. They will now have a filled block in the test fixture, with the hash that we validated is correct, and they should indeed correctly raise on an invalid hash according to the spec.

Am I missing anything @raxhvl? Does this go along with what you were thinking @marioevz?